Backport of the Bitshares bitshares/bitshares-core#339

Tl;dr: if during startup we have a (possibly old) object_database available, we should use it.

We have up to two on-disk representations of the blockchain state: the block log and the object_database. The object database can be reconstructed from the block log, this is what a "replay" does. A replay takes a long time, and this time is constantly growing. This PR is an attempt to mitigate that.

During startup, the application checks the availability and state of the on-disk representation. The old code applies some rather restrictive logic (object_database.head_block == block_log.last_block) to determine if the state from the object_database can be used. This prevents creating and using snapshots of the object_database.

The logic implemented by this PR is more natural, IMO:

If we have an object_database, we should use it. Only if object_database.head_block > block_log.last_block we have an inconsistency (we cannot reconstruct that object_database from that block_log). In that case, treat the object_database as if it were absent.
If we don't have an object_database, use genesis.
From where we are now (genesis or object_database.head), replay all additional blocks from the block_log.
If during step 3 we come across block_log.last - 10000 (an arbitrary number about 8 hours in the past), flush the object_database to disk, and continue. This snapshot will be available in the next restart, if the node crashes or does otherwise not exit cleanly.
During step 3, at 50 blocks before block_log.last (another arbitrary number, about twice the number of active witnesses), switch from apply()ing blocks to push()ing blocks. This will populate the fork_database and enable switching to a different fork, if our block_log ends in a fork.

This change will greatly improve startup time for nodes, which will be particularly important ifwhen we experience another blockchain halt, like a couple of weeks ago.